ISO/IEC 27035 : La norme incontournable pour structurer la gestion des incidents de sécurité

Aucun système n’est à l’abri d’un incident de sécurité. La norme ISO/IEC 27035 fournit un cadre clair et structuré pour détecter, traiter et tirer des enseignements de chaque incident. Cet article détaille ses principes essentiels et explique comment construire une politique de gestion des incidents réellement efficace.

Par: Joachim Fontfreyde · 2025-06-30

Aucun système n’est infaillible. Ce qui différencie une organisation mature d’une autre, ce n’est pas l’absence d’incident, mais sa capacité à y répondre avec méthode.

C’est pour sortir d’une logique réactive qu’a été créée la norme ISO/IEC 27035, dédiée à la gestion des incidents de sécurité de l’information.

Les 5 étapes de la norme ISO/IEC 27035

La norme ISO/IEC 27035 repose sur une approche structurée en cinq grandes étapes, qui permettent de cadrer l’ensemble du processus de gestion d’un incident de sécurité, du signalement initial jusqu’à l’amélioration continue.

1. Préparation

Mettre en place l’organisation et les moyens nécessaires pour être prêt à réagir. Cela inclut la définition des rôles (qui fait quoi), la rédaction des politiques et procédures, la formation des équipes, et le déploiement d’outils de détection.

1. Détection et enregistrement

Un incident peut être détecté par une alerte technique (SIEM, EDR), un utilisateur vigilant, un fournisseur, ou même un journaliste.

Quelle que soit la source, il est essentiel de disposer d’un processus clair pour identifier ce qui se passe, enregistrer les informations clés (date, système concerné, symptômes, etc.), et lancer la mécanique d’analyse.

1. Evaluation

Une fois l’incident détecté, il faut le qualifier. S’agit-il réellement d’un incident ? Est-il critique ? Qui est concerné ? Quelles données sont potentiellement en jeu ?

Cette phase permet de mesurer l’impact réel (ou potentiel), d’évaluer la portée, et de décider s’il faut escalader le cas, informer des parties externes (comme la CNIL en cas de données personnelles), ou activer une cellule de crise.

1. Traitement

C’est la phase d’action : on cherche à contenir l’incident pour éviter qu’il ne s’aggrave (ex : isoler un poste compromis), puis à éradiquer la cause (supprimer un malware, corriger une faille), et enfin à restaurer les systèmes affectés dans un état sain.

Cette étape doit être conduite avec méthode et coordination, en s’appuyant sur des procédures claires et éprouvées.

1. Apprentisssage

Une fois l’urgence passée, l’organisation doit prendre du recul. Que s’est-il passé ? Qu’est-ce qui a bien fonctionné ? Qu’est-ce qui a manqué ?

Cette phase de retour d’expérience permet de tirer des leçons, d’ajuster les procédures, de corriger les failles identifiées et, au final, de renforcer la posture sécurité globale.

C’est un levier majeur d’amélioration continue dans une logique ISO.

Ce que doit contenir une politique de gestion des incidents (conformément à ISO/IEC 27035)

Pour être efficace, une politique de gestion des incidents ne doit pas être un document purement formel. Elle sert à donner un cadre clair aux équipes, pour savoir quoi faire, quand, et comment réagir en cas d’incident.

Conformément à ISO/IEC 27035, elle doit au minimum inclure les éléments suivants :

1. Définition et périmètre

Elle doit expliquer ce qu’on appelle un incident, un événement ou une alerte. Elle doit aussi préciser quels types d’incidents sont couverts : cyber, techniques, humains, liés à des tiers, etc.

1. Rôles et responsabilités

Qui est en première ligne pour détecter un incident ? Qui décide si l’incident est critique ? Qui communique vers la direction ou l’extérieur ? Ces rôles doivent être clairement attribués (équipe IT, RSSI, métiers, CSIRT…).

1. Processus à suivre

La politique doit décrire les grandes étapes du traitement d’un incident : préparation, détection, évaluation, réponse, retour d’expérience. Elle doit aussi préciser quels outils ou canaux sont utilisés (SIEM, tickets, procédures internes…).

1. Priorisation

Tous les incidents ne se valent pas. Il faut prévoir une grille simple pour les classer (mineur, majeur, critique) et définir à quel moment on doit escalader (par exemple si des données personnelles sont exposées ou un service est coupé).

1. Communication

Qui faut-il prévenir ? À quel moment ? Et par quels canaux ? Il est utile d’avoir des modèles de messages prêts à l’emploi (communication interne, vers les clients ou les autorités).

1. Obligations légales

Si l’incident touche des données personnelles ou des systèmes critiques, il peut être obligatoire de le déclarer dans un délai donné (ex. 72h pour le RGPD). La politique doit rappeler les délais et les autorités concernées (CNIL, ANSSI, etc.).

1. Retour d’expérience

Une fois l’incident clôturé, il est essentiel d’en tirer des leçons. La politique doit prévoir l’organisation de réunions post-incident, le suivi des actions correctives, et le lien avec la gestion des risques ou les audits sécurité.

Quelques règles pour que la politique soit vraiment utile

Une bonne politique ne doit pas être un pavé oublié sur un SharePoint. Elle doit être claire, concise et applicable. Voici les bonnes pratiques à respecter :

• Limiter le document à l’essentiel : mieux vaut un document lisible de 5 à 10 pages qu’un roman de 40 pages que personne ne lit.
• S’assurer qu’elle est validée, à jour, diffusée (preuve à l’appui).

Ne pas confondre politique et procédure

La politique donne la direction, la procédure donne la méthode. L’une sans l’autre n’est pas suffisante : sans politique, on navigue sans cadre ; sans procédure, on improvise à chaque incident. Les deux doivent donc exister, être cohérentes, à jour, et connues de ceux qui les appliquent.

• La politique définit le cadre général : elle explique qui fait quoi, quand, et dans quelles conditions. Elle précise les rôles, les responsabilités, les obligations légales (comme le délai de notification à la CNIL), les niveaux de criticité, et les grandes étapes du processus.
  • Elle est généralement courte (5 à 10 pages), validée par la direction, et destinée à cadrer l’action de l’ensemble de l’organisation.
• La procédure, elle, est opérationnelle. C’est une procédure technique détaillée, qui explique précisément comment faire dans une situation donnée. Elle est pensée pour les équipes en première ligne : analystes, techniciens, SOC, équipes de réponse. On y retrouve les outils à utiliser, les étapes pas à pas, les scripts, les commandes, les modèles de messages, les liens vers les tickets, etc.
  • Par exemple : comment bloquer un compte compromis, comment analyser un mail suspect, ou comment restaurer une VM chiffrée.

ISO/IEC 27035, un maillon dans une chaîne plus large

La norme est conçue pour s’imbriquer avec :

• ISO/IEC 27001 : stratégie sécurité et SMSI
• ISO/IEC 27002 : catalogue de mesures de sécurité
• ISO/IEC 27005 : gestion des risques
• ISO/IEC 22301 : continuité d’activité (en cas d’incident majeur)

C’est donc un élément central dans la mise en place d’un Système de Management de la Sécurité de l’Information (SMSI).

Gérer les incidents, c’est piloter, pas subir

La norme ISO/IEC 27035 vous donne les clés pour structurer cette capacité de réaction. Pas besoin d’être une multinationale pour l’appliquer : une politique claire, des rôles définis, un cycle de gestion éprouvé et une logique d’amélioration continue suffisent pour transformer chaque crise en opportunité d’apprentissage.

Formaliser la gestion des incidents, ce n’est pas cocher une case. C’est construire les fondations d’une cybersécurité sérieuse, durable, et alignée avec la réalité du terrain.

Chez Keepya, c’est cette vision que nous défendons : intégrer ce cadre ISO dans une approche simple, concrète et actionnable pour piloter vos risques, vos contrôles, et vos incidents, sans complexité inutile.